This requires infinite lookahead for parsing if I am not mistaken, a method call expression can begin with any expression which we cannot differentiate from a pattern without attempting to parse the whole construct first. This is I believe the reason as to why assignment destructuring (pat = expr) doesn't parse full patterns either, it accepts a subset of expressions on the lhs and interprets those are patterns.

As specified below, the MethodCallExpression always starts with an identifier, so this is not a parsing issue right now. But it is indeed problematic if we want to relieve this restriction in the future.

My mental model would be to parse it like this:

if peek("mut") { parse("mut") }
if peek(Identifier) && !peek("=") {
    UnnamedMoveBInding { parse(Expr)}
} else {
     NamedMoveBinding { parse(Pattern), parse("="), parse(Expr) }
}

This is not accurate.
Bindings are "captured by example", so if the closure needs a reference to the value it's captured by reference and if needs an owned value it's captured by move...except for Copy types which always capture by reference unless you move.

Issue with more details:
rust-lang/rust#100905

I think we should consider changing this behavior in a new edition and seeing if this helps without needing new syntax.
Personally for me every time I need the workarounds described in this RFC it was because of this.

Does it sound reasonable and feasible to detect this as a breaking change and fix/warn in automated edition migration tools?

I might be missing some implied boilerplate here, but is this just two lines?

It could be just one line (and maybe even inlined in another expression). So that's 3.5 lines of boilerplate.

Should this be left as a future extension?

1. It is just syntactic sugar, having the same effect as move(mut foo = foo.clone()).
2. It's a bit weird that only a subset of expressions are allowed -- namely, those where the first token is an identifier.
3. It should possibly be extended so that move(mut self.foo.clone()) yields move(mut foo = self.foo.clone()).
4. There's no precedent for introducing such bindings. In particular, arguably, it should work similarly in constructors: Self { foo.clone() } should be short-hand for Self { foo: foo.clone() } for consistency.

I think it would be easier to first focus on the idea of explicit capture -- and whether it's worth it -- and defer the special short-hand notation for later, and thus that it would make sense to move this to a possible future extension.

I agree this should be left for future, if added at all.

By looking at move(mut foo.clone()), it is unclear what it should bind to. In this situation, foo is the only ident but in move(mut foo.bar.clone()), is it supposed to be bound to bar or foo? That sort of ambiguity isn't a good thing to add.

that's why it is strictly limited to a single identify in the method call receiver.

I'd like to ask for a special sigil for this "and other implicit captures" behavior:

move(x, y, ..) || { … }

Indeed, by requiring a trailing .. in order to allow implicit captures:

• such implicit capture is now clearer: the x, y enumeration is now visibly non-exhaustive;
• it gives the option not to provide , .., thereby requiring exhaustive enumeration of captures: this gives the power to the person defining the closure to restrict the kind of captures a closure may use.
  • Given that the motivation for this syntax is finer-grained control, it would be a pity not to be featuring such a capability, and have to wait for a later edition-requiring amendment to get into this behavior.
  • reasons for restricting external captures can be:
    • soundness of more advanced designs (e.g., macros and advanced lifetime shenanigans);
    • especially in FFI or other type-erased scenarios where certain lifetimes may have been lost;
    • (or when worried about things like {A,}Rc cycles in case of implicit by-move captures)
    • better control of a closure size;
    • helps teachability of how closures work: move(x) |…| { … } would always be an x-capturing closure, no matter the body of ..., thereby properly decoupling implementation details from API surface (of the closure type).
• it mirror struct pattern destructuring, wherein a Foo { x, .. } pattern is not expected to be exhaustive over the fields it has, whereas Foo { x } is.

Indeed, by requiring a trailing .. in order to allow implicit captures:

Do you mean implicit captures by-value? or keeping the current default capture behavior (without move)? Foo { x, .. } means all fields except x are ignored so it would make sense if all fields other than x were ignored in move(x, ..) when doing move captures

Note that writing move(&some_var) is not that much longer than move(some_var), so this argument may be a bit weak (to clarify, in a vacuum / ceteris paribus, I'm on board with this argument; but in this case, it may not pull its weight compared to the advantages of by-move implicit captures).

Once this RFC lands, I could imagine there being a lint against implicitly by-move-captured mut bindings, be it through move ||, or through move(..) || 🙂 (warn-by-default for the latter, and the former requiring the edition dance)

Ughh, I have to admit to finding this rather counter-intuitive:
I'd have expected move() || to be closer to move || than to ||

I'd like to suggest the opposite, here, actually: for move(..) (or move() if the suggestion for .. is rejected) to mean the same as move.

• big consistency gain: move(..) || being closer to move || than to ||;

• make by-reference captures be the odd one that stands out. I agree this may be subjective, but bear with me:

  There are two kind of closures:

  • immediately-called closures, such as with Option::map() or panic::catch_unwind();
  • long-lived closures (: 'long), such as the spawn() family.

  The former, 99% of the time, accomodates to fully implicit || {} capture rules, and the latter, kind of accomodate to move || closures, except for when specific "right-before move adjustments" are needed, which is very often just a .clone() (and sometimes an Arc::downgrade()).

  This very RFC, by providing explicit captures, is thus mostly helping the latter case: the one with : 'long-lived requirements. In such a scenario, capturing by reference is rather non-desired, or something niche stemming from a having long-lived borrowable available (e.g., borrowing a variable but because it would happen to outlive the 'env of a scope::spawn())). It thus does seem rather legitimate to favor by-move captures for the ..-implicit ones, much like move || does.

• lastly, although I agree this one may not be that important to others, I feel like it would be the most helpful syntax w.r.t. teachability: with the current semantics of implicit by-ref captures for move(..), it would mean having borrows by using the move keyword, which kind of denaturates/dilutes the meaning of that word. Whereas in the case of move(..) implicitly capturing by move, the explicit move(&x) would be justified insofar the word move would have been itself neutered/overriden by the explicit & sigil.

I think, rather than adding move(..) (which could just be written move) or move() (which could just be omitted), we should have a warn-by-default lint for an empty capture list (with a suggestion that removes it and a note that mentions using move if you want to capture everything), and add it to the list of lints suppressed in macros (since macros might want to generate a capture list).

I think it would be quite valuable to also have move(&x, &mut y) syntax, for the specific cases of explicit by-reference captures:

• not only for my suggested implicit-by-move change, should it be accepted;
• but even in the case of the current implict-by-ref-captures semantics of the RFC, when wanting to be explicit, it would be nicer to be using move(&x, &mut y) than move(x = &x, y = &mut y), especially when x and y are longer_variable_names.
• there would otherwise be no way to mimic, explicitly, the "magic binding" semantics which implicit by-ref closures captures currently have (e.g., when having x: i32, an implicit by-ref capture of x makes it so the closure has captured &x, but the x name is still fully usable to refer to the *&x place).

If we didn't have this sugar, I could very well see myself having a .by_ref() and .by_mut() couple of blanket-implemented extension methods.

• whilst these methods could be a bearable alternative, I don't think it's worth the hassle w.r.t. adding another 1-lookahead case for these parsing rules:

    $(mut)? $binding:ident $(. $method…)?
OR
    &$(mut)? $binding:ident
OR
    $binding:pat = $e:expr

I agree this should be left for future, if added at all.

By looking at move(mut foo.clone()), it is unclear what it should bind to. In this situation, foo is the only ident but in move(mut foo.bar.clone()), is it supposed to be bound to bar or foo? That sort of ambiguity isn't a good thing to add.

I just noticed that GitHub renders move() with the color of a function call instead of as a keyword. This adds to the previously discussed problem of ambiguity as a function call.